https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html

在這篇文章中有提到一些針對 graphql 常見的一些攻擊如下 :

• injection : 這裡包含以下幾種不同類型的攻擊
  • SQL 與 NoSQL injection
  • OS command injection
  • SSRF 與 CRLF
• Dos ( Denial of Service )
• 使用破損的 authorization 進行攻擊，包含不適當與過多的權限，也包含 IDOR 攻擊。
• batching 攻擊
• 使用不安全的 default configurations

然後根據上面的資安攻擊問題，這篇文章提供了一些 best practices 給我們參考 :

1. Input Validation

就是我們使用 graphql 的 query 或 mutation 時都會有 input，這裡就是會有資安風險的地方，所以這裡有給一些建議 :

General Practices

• 驗證所有傳入的資料，僅允許有效的值，限制越多越安全。

• 使用 graphql 的 data types 像scalars與enums，因為可以防止不符合預期資料進來，並且限制了輸入範圍。

• 列出允許的characters，這一點我自已好像開發時的確有時後會沒有注意到，有時一個簡單的 title 就用 string 類型，但是卻沒有檢查能能帶那些character。

• 使用 reject invalid input，然後要注意錯誤訊息不會有太多資訊，因為會越容易讓 hacker 知道你家長什麼樣。

Injection Prevention

• 使用一些安全的 libary 所提到的 api。

• 使用 orm 或 odm，但是也需要注意 orm injection。

• 如果沒辦法使用上面那些工具，則儘可能的將 input 進行 escape 或 encode。

Process Validation

即時對使用者的 input 有進行清理 ( sanitized ) 與驗證 ( validated )，仍然需要小心使用這些 input。

• 限制使用者對 data flow 的控制。

• 不要將使用者提供的 input，直接丟到資料庫或是進行 http 請求。

2. DoS Prevention

DoS ( Denial of Service ) 是一種針對 api 的 availability 與 stability 的攻擊，它可能使 api 變慢、或是完全不可用。

通常手法就是爆力打，然後耗盡系統資源，使服務變得無法正常運作。

所以這裡有提供一些 graphql 防止 Dos 的建議設計 :

• 限制 query 的深度。

• 限制 query 的數量限制 ( graphql 的一個請求可以有多個 query ) 。

• 要有 pagination。

• 有 timeout。

• 增加針對每個請求 ( By IP or User )進來的 rate limiting，防止 Dos。

• 使用 dataloader。

• 使用 graphql query cost analysis 來知道一個 query 的成本。

• 限制 system resource。

3. Access Control

這個是幾乎每個層級都會提到的東西，然後這裡給人一些針對 graphql access control 的建議 :

• 每一次請求都要驗證請求者是否有權限，可以使用RBAC來實現，這樣可以防止 IDOR、BOLA、BFLA 攻擊。

• 執行 authorization check 時再每個 schema 都需要檢查，文章提到是這個資安事件。簡單的說正常的 query path 如下 :

  query {
    users() {
      edges {
        node {
          email
        }
      }
    }
  }
  

  然後現在的 authorization 只有 check edges，但是 node 沒有，因此如果使用以下的 query path 就會有資安問題 :

  query {
    users() {
      nodes {
        email
      }
    }
  }
  

• 使用 graphql 的interfaces與unions，來建立結構化的類型，可以根據這些類型，來進行權限控管。

• 禁止在 production 使用 introspection queries，它是一個在開發時常見的工具，它可以回傳包含 types、fields、mutations 相關很多的 metadata。

4. Batching Attacks

在 graphql 中，我們可以使用以下的 query batching :

[
  {
    query: < query 0 >,
    variables: < variables for query 0 >,
  },
  {
    query: < query 1 >,
    variables: < variables for query 1 >,
  },
  {
    query: < query n >
    variables: < variables for query n >,
  }
]

這裡就會有不少資安風險，所以這裡給了一些建議 :

• request rate limiting。

• 禁止的敏感的 schema 進行 batching，因為 batching 就代表可以進行爆力破解嘗試，所以有這個限制，它就沒辦法 try 出密碼的概念。

• 限制可以同時 batching 的數量。

5. Securing Configurations

• 不要回傳多餘的錯誤訊息，例如關掉 stack traces 與 debug mode。

• 只有在真的需要時，才開啟GraphQL Introspection。

工具集

• InQL Scanner : 它注意是 graphql 的測試工具，主要是在資安這一塊的東西。

• GraphiQL : graphql ide 工具。

• GraphQL Voyager : 這個也一樣是 ide 工具，但它可以有 graph 看到 schema 的關係。